Implement subresources in VWs - #4342

Was this always the case?

Yes, we just never checked for subresource permissions because only implemented status so far.
Given kube also doesn't give implicit access to the status subresource - but requiring this now would break existing APIExport/-Bindings.
I wanted to bring this up in todays community meeting to see how we feel about this.
On one hand I'd rather we are exact, on the other I'm not sure how we could make this "nice" for end users.

E.g. we could gate the implicit status on a feature gate, but that isn't really nice.
We could just keep status being implicit for now and require it explicitly in the next API version.
But I'm not really a fan of either.

Albeit not on paper, but the "spirit" of offering a service is for the consumer to give the spec, and provider to update the status - so I think it's assumed the provider needs access to that at all times, even when claiming. So if we're looking for an excuse to keep these perms implicit, I think this could be one :D but it does sound a bit weak.

I mean yeah but for resources exported via an APIExport we are already implicitly claiming the resource and the subresources^^
But I get what you mean. Plus that subresources are only really interesting for update/patch, so at that point the consumer is already accepting mutations from the provider on the claimed resource - and that could include subresources.

Is this TODO still relevant?

Yes. CRDs can support the scale subresource, so technically a CRD could be exported via an APIExport that supports the scale subresource.
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource

But why is it different than status? Isn't this PR working for all subresources?

Not all, but making it possible to handle subresources other than status with the changes to permission claims and handling it in authorization.

I can take a stab at implementing the scale subresource as well for completeness :D
I'm not sure if scale is actually different or if sttts just didn't bother with it at the time.

But I think there's more work down the line because I'm not sure how well this works for e.g. virtual resource. But I haven't used virtual resources at all so far so 🤷

kk

Done :D Scale subresource works!

Does this meant that if I claim named resource virtualmachine I will get all other virtualmachines subresources?

It just means that you can apply a selector on top of the selectors for the parent resource.

e.g. you have the virtualmachines resource with label my.exposed.resources=true and then you claim the subresource virtualmachines/ssh you cannot apply another label filter on top.
I had that implemented and I see some use for it (I mentioned that in the description) but I don't think that too many people will use it.
The story is basically "when you claim a subresource you must have access to its parent".
Hence the CEL validation that the selector must be matchall.

This sets MatchAll = trueunconditionally, even when the user explicitly set matchLabels/matchExpressions on the subresource claim. ValidateAPIBindingPermissionClaims then rejects with "matchLabels cannot be used with matchAll" — for a matchAll the user never wrote, which will be very confusing to debug :)

The user cannot set matchlabels/-expression; I added a CEL rule for that.
Maybe the rule doesn't hold in which case I have to fix that :D

Bit of AI explaining as it did better job than I did. I think this is important one , if not most. I tried to look to this via "controller-runtime generated patterns"

What the API now allows:
The new regex on resource accepts anything shaped like foo/bar — including cowboys/status. Nothing anywhere rejects .../status as a claim. So you can write it in an APIExport and APIBinding, and it gets accepted and stored.

What the authorizer actually does with status requests:
When a request comes in for a status subresource, the authorizer deliberately ignores the subresource and looks for a claim on the parent resource only:

// binding.go
claimedResource := normalizedGR.Resource            // "cowboys"
if sub != "" && sub != "status" {                   // status is skipped!
    claimedResource = resource + "/" + sub
}

So for a status update, it searches your claims for cowboys — never for cowboys/status.

The trap:
Imagine a provider who thinks in RBAC terms (which the docs literally encourage — "in the style of RBAC rules"). In RBAC you'd write:

cowboys → verbs get, list (read the objects)
cowboys/status → verbs update (write only the status)

That's a completely reasonable, even best-practice layout. But here's what happens:

1. Both claims are accepted. No error, no warning. ✅ (looks fine)
2. Provider tries to update a cowboy's status.
3. Authorizer looks for a claim on cowboys with verb update.
4. The cowboys claim only has get, list → denied.
5. The cowboys/status claim with update? Never consulted. It's a dead claim — it exists, it's accepted, and it does absolutely nothing.
6. The user gets a permission denied and has zero indication that their cowboys/status claim is being ignored. They'll stare at it and think "but I claimed it right there!"

Why "accepting-but-ignoring is the worst of both":
There are two consistent designs:

Status is implicit → then writing foo/status should be rejected with a clear message ("you don't need this, status comes with the parent claim").
Status is explicit → then foo/status claims should actually work in the authorizer.

The PR does neither: it accepts the claim syntactically but ignores it semantically. That's the worst combination, because the API lies to the user.

The suggested fix (cheap one):
Add a CEL validation so it's impossible to write:

rule: "!self.resource.endsWith('/status')"
message: "status is granted implicitly by the parent resource claim"

Now the user who writes cowboys/status gets an immediate, self-explanatory error at creation time instead of a silent no-op at request time.

and we need e2e to for this

The fix the AI suggested with not allowing the status subresource is what I mentioned in call earlier; but before we make a decision on that I think we should discuss it in the cc to see what people think.

Personally I would prefer having status implicit for this API version and not allow setting it and requiring it to be explicit in the next API version.

This is missleading a bit.

Maybe: "for subresource claims the selector is ignored; scope is inherited from the parent resource claim".